In file @apps/server/src/provider/NativeProtocolLogging.ts around line 33:

In the object branch, `Object.keys(record).length` builds an array of every own enumerable key. A large untrusted payload with many fields therefore allocates memory proportional to the field count, which can exhaust the server while producing diagnostics that are supposed to be bounded. Consider counting keys without materializing the full array.

In file @apps/mobile/src/features/threads/ThreadFeed.tsx around line 1690:

`ThreadWorkLog`'s overflow toggle calls `onToggleWorkGroup` with the containing activity-group's `entry.id`, but `onToggleWorkGroup` hardcodes the anchor key as `work-toggle:${groupId}`. So `disclosureAnchorKeyRef` holds `work-toggle:<entry.id>`, which never matches any list item's actual `key` (`entry.id`). `shouldRestoreVisibleContentPosition` then rejects every visible item during the inline group expand/collapse, so the list fails to preserve the user's viewport and can jump as rows are inserted or removed. Use the activity-group entry ID directly as the anchor key instead of prefixing it.

In file @packages/client-runtime/src/state/models.ts around line 171:

`presentThreadShell` treats every pending request kind except `user_input` and `auth_refresh` as an approval, so a thread with `pendingRuntimeRequest.kind === "dynamic_tool_call"` reports `hasPendingApprovals: true`. That surfaces a false approval indicator even though there is no approval the user can open or answer. Consider excluding `dynamic_tool_call` (and any other non-approval kinds) from the `hasPendingApprovals` check, matching the exclusion already applied elsewhere.

In file @apps/server/src/textGeneration/CursorTextGeneration.ts around line 126:

When the Cursor SDK returns `status: "cancelled"` or `status: "error"` but still populates `result` with partial text, `runCursorJson` proceeds to decode that text and returns it as a successful generation. The status check on line 126 only guards against empty `result`, so non-empty partial output from a cancelled or failed request bypasses the error path. Consider rejecting any non-`finished` status before inspecting `promptResult.result`.

In file @apps/server/src/orchestration-v2/ContextHandoffService.ts around line 147:

`makeProviderHandoffSummary` labels `fromProviderInstanceId` and `toProviderInstanceId` as "From driver" / "To driver", but these are user-defined provider instance IDs (routing keys), not driver kinds. The handoff summary text therefore reports incorrect provider identity metadata to the model whenever an instance ID doesn't match its driver kind. Consider labeling these as provider instances, or passing and displaying the actual driver kinds.

In file @apps/mobile/src/state/use-thread-selection.ts around lines 62-70:

`threadDetailToShell` includes `queued` in the active-run lookup, so when a later run is `queued` while an earlier run is still running, it sets `activeRunId` to the queued run and reports its status — hiding the actually running run until the shell list materializes. The canonical shell derivation excludes `queued` from active runs and always derives `status` from the latest run. Remove `queued` from the active-run predicate and use `latestRun?.status` for `status`.

In file @packages/client-runtime/src/operations/commands.ts around line 360:

`updateThreadMetadata` dispatches two separate commands for one logical update. When the first command (metadata fields) succeeds but the projection fetch or the second command (model selection / provider switch) fails, the effect reports failure even though the first mutation was already committed. A retry then produces a partially applied update rather than the all-or-nothing behavior the API implies. Consider combining the mutation server-side or returning an explicit partial-result type so callers know the first half succeeded.

In file @apps/web/src/components/BranchToolbar.tsx around line 256:

When `layout="panel"` and only a single non-primary environment is available, the panel renders workspace and branch rows but never renders any environment indicator. The caller in `ThreadDetailsPanel` only adds a separate `BranchToolbarEnvironmentSelector` when `availableEnvironments.length > 1`, so the single-remote-environment case — the exact scenario `shouldShowEnvironmentIndicator` exists to surface — is silently hidden in panel mode. In `composer` mode the same case is handled by the `showEnvironmentIndicator` branch, but the panel return path skips it entirely. Consider rendering the environment indicator (either inline or via `BranchToolbarEnvironmentSelector`) in the panel layout as well.

In file @apps/server/src/orchestration-v2/Adapters/OpenCodeAdapterV2.testkit.ts around lines 209-211:

The `events` async generator hangs forever when the transcript entries are exhausted without a trailing `runtime_exit` entry. The loop calls `await this.changed(signal)` and blocks indefinitely because nothing ever advances the cursor or resolves the waiter. The schema permits an empty or truncated `entries` array, and `assertComplete()` treats EOF as complete, so this scenario is reachable. When `this.cursor >= this.transcript.entries.length`, the generator should return instead of waiting.

In file @apps/server/src/orchestration-v2/Adapters/CursorAgentSdk.ts around lines 306-308:

The layer creates a batched `EventNdjsonLogger` (200 ms flush window) but never calls its `close()` method — `assertComplete` is `Effect.void`, so on layer shutdown the per-thread writer scopes stay open and any records still in the batch window are dropped. Consider yielding `nativeEventLogger.close()` via `Effect.addFinalizer` so pending records are flushed before the layer disposes.

In file @packages/client-runtime/src/operations/commands.ts around line 204:

`persistAttachments` sends only the filtered `uploads` array to `assetsPersistChatAttachments`, so the server computes each persisted attachment's ID from its index within that filtered list. When a message mixes already-stored attachments with new uploads, the uploads are renumbered starting at 0, which can collide with an existing stored attachment's `${messageId}:${index}` ID — overwriting the stored file and producing duplicate attachment IDs in the returned message. Consider sending the original indices alongside the uploads (or including placeholders for stored attachments) so the server derives non-colliding IDs.

In file @packages/client-runtime/src/state/threadWorkflows.ts around line 37:

When no active provider thread is resolved from the active run, `resolveThreadProviderSession` picks the first provider thread attached to the app thread via `find`, ignoring thread status. Because historical provider threads persist across handoffs and forks, this can attach a stopped or errored provider thread whose session is stale — causing queue/steering and detach actions to be gated by the wrong capabilities or disabled entirely. Consider filtering for provider threads whose session is not `stopped`/`error`, or selecting the most recently active thread before resolving its session.

In file @apps/server/src/orchestration-v2/Adapters/OpenCodeAdapterV2.testkit.ts around line 151:

In `OpenCodeReplayController.response`, replies are correlated only by `frame.operation`, so concurrent requests for the same SDK operation can receive each other's data. For a transcript ordered as outbound A, outbound B, response A, response B: request A waits at outbound B, then request B consumes response A (its `operation` matches), and A consumes response B after being awakened — silently swapping replay results and making concurrent same-operation replays incorrect. Consider correlating by per-request ordering (e.g., matching the Nth response for an operation to the Nth pending request) instead of matching only `frame.operation`.

In file @apps/server/src/checkpointing/CheckpointDiffQuery.ts around line 228:

When `getFullThreadDiff` calls `getTurnDiff` for a range that is unavailable, the error returned (e.g. `CheckpointTurnRangeUnavailableError`) has its `operation` field set to `CheckpointDiffQuery.getTurnDiff` instead of `CheckpointDiffQuery.getFullThreadDiff`, producing misleading error messages and telemetry that identify the wrong RPC. This happens because `getFullThreadDiff` delegates to `getTurnDiff`, which hardcodes `const operation = "CheckpointDiffQuery.getTurnDiff"` and uses it for every error it constructs. Consider accepting an `operation` parameter on `getTurnDiff` so callers can supply the correct operation context.

In file @apps/server/src/orchestration-v2/ContextHandoffService.ts around line 126:

`makeProviderHandoffSummary` includes every turn item with no size or item-count limit. When `strategy` is `full_thread_summary` and the caller passes the entire `projection.turnItems` history, a long-lived thread produces an arbitrarily large handoff summary that is prepended directly to the next provider message. This unbounded summary can exceed the provider's context window, preventing the resume-fallback run from starting instead of providing a bounded summary. Consider capping the number of summarized items or the total summary text length, similar to the `compactText` per-item limit, so the handoff stays within context-window bounds.

In file @apps/server/scripts/probe-claude-fork-local-rollback-replay.ts around line 224:

`sanitizeValue` does unrestricted substring replacement, so when `cwd` is a relative path like `.` (the default from `makeCheckpointWorkspace`), every period in every transcript string gets replaced with the synthetic directory. This silently corrupts version numbers, prose, and filenames throughout the generated replay fixture instead of only normalizing filesystem paths. Consider resolving `cwd` to an absolute path before building `pathFragments`, or skip fragments that are too short/ambiguous to be safe for global substring replacement.

In file @apps/server/src/scheduledTasks/ScheduledTaskService.ts around line 124:

`decodeRow` calls `ScheduledTaskId.make(row.task_id)` outside the schema-decode pipeline. When `task_id` is corrupt (empty or whitespace), this throws a defect instead of producing the typed `ScheduledTaskError` that `Effect.mapError` wraps. The lenient scheduler uses `Effect.result(decodeRow(row))`, which does not catch defects — so a single malformed row aborts the entire poll loop instead of being skipped and logged. The `mapError` handler also repeats `ScheduledTaskId.make(row.task_id)`, which can throw the same defect. Consider constructing `ScheduledTaskId` inside the schema (or within the generator body) and passing the raw `row.task_id` into `taskError` so both the decode failure and the error handler stay defect-free.

In file @apps/web/src/components/chat/V2ItemInspector.tsx around line 176:

The `file_search` and `web_search` result lists use `JSON.stringify(result)` as the React `key`. When the provider returns duplicate result objects, the sibling keys collide, which causes React reconciliation to reuse or render the wrong row on subsequent updates. The key should include the array index or another occurrence-unique value.

In file @apps/web/src/components/chat/MessagesTimeline.tsx around line 1523:

`WorkGroupSection` keeps its `isExpanded` state in a local `useState`, so when `LegendList` virtualizes the row away and later remounts it, the expanded state resets to `false`. A user who expands a work group, scrolls away, and scrolls back sees the group collapsed again, losing their interaction. Previously this state lived in the parent (`expandedWorkGroupIds`) and survived row virtualization. Consider lifting the expanded-work-group state back to the parent so it persists across mount/unmount cycles.

In file @packages/effect-codex-app-server/src/replay.ts around line 149:

The module-global `decoder` in `replay.ts` is shared across all replay clients. Because `processOutboundChunk` calls `decoder.decode(chunk, { stream: true })`, the streaming decoder retains partial multibyte state between calls. When two replay clients run concurrently and their UTF-8 chunks split a multibyte character, they corrupt each other's decoder state, producing spurious JSON parse or frame-mismatch failures. Each client should create its own `TextDecoder` inside `makeReplayClientWithState` instead of using the module-global `decoder`.

In file @apps/server/src/ws.ts around lines 187-197:

`persistChatAttachments` uses `writeFile` with an exclusive-create flag, so re-sending the same RPC (same `threadId`, `messageId`, and attachment index) overwrites the file on disk that an already-stored message references, silently altering historical message content. The deterministic path means re-persisting the same logical attachment always targets the same file. Consider rejecting writes to an existing destination (e.g., an exclusive create that fails if the file exists, or comparing existing bytes) so prior message content cannot be changed.

In file @apps/server/src/orchestration-v2/Adapters/GrokAdapterV2.testkit.ts around line 41:

The replay layer creates `replayDir` via `fileSystem.makeTempDirectory` but never cleans it up on scope finalization, so each replay run leaves a temp directory (containing `status.json`) behind in the OS temp area. These directories accumulate across repeated test runs. Consider scoping the temp directory so it is removed when the layer's scope closes.

In file @apps/server/src/orchestration-v2/testkit/fixtures/claude_result_is_error/output.ts around lines 40-42:

`failedTurn` is selected as *any* provider turn whose status is not `completed` or `running`, without linking it to `failedRun`. If run 1's own provider turn actually completed while a *different* run's provider turn failed, this assertion still passes — it never verifies that run 1's provider turn is the failed one, despite the comment stating that requirement. Consider filtering `failedTurn` by `failedRun?.id` (e.g. matching `turn.runId === failedRun?.id`) so the assertion checks the correct turn.

In file @apps/server/src/orchestration-v2/Orchestrator.ts around line 5339:

`layerUnavailable.resumeQueuedRuns` fails with an `OrchestratorDispatchError` whose `commandType` is `"message.dispatch"`, so any log or UI surface that renders `commandType` misidentifies the failed operation as a message dispatch instead of the system resume-queued-runs action. The fallback should use a `commandType` that reflects the actual resume operation so the error is distinguishable.

In file @apps/server/src/orchestration-v2/CheckpointCaptureService.ts around line 99:

When `checkpoints.capture` returns a checkpoint with `status: "error"` (VCS capture failure), `execute` still commits that checkpoint and marks the run and node as `"completed"` with its `checkpointId`. On any retry, the early idempotency check sees a completed run with a non-null `checkpointId` and returns immediately, so the failed checkpoint is never recaptured. The stored checkpoint is also unrestorable — `CheckpointServiceV2.restore` rejects non-`ready` checkpoints — leaving the run permanently stuck. After calling `checkpoints.capture`, the code should inspect the returned checkpoint's `status` and avoid committing a completion event when it is not `ready`.

In file @apps/server/src/provider/acp/AcpSessionRuntime.ts around line 214:

When cgroup containment is enabled, `wrapCommandForLinuxCgroup` spawns the command via `process.execve`, which drops the normal `execvp`/`posix_spawn` fallback that retries through `/bin/sh` on `ENOEXEC`. A provider command that is a text script without a recognizable shebang (no leading `#!`) works normally but fails under cgroup containment because `execve` returns `ENOEXEC` and the wrapper exits 125. Consider falling back to `/bin/sh -c` on `ENOEXEC` before calling `process.execve`, or document that cgroup-contained commands must have a valid shebang or be directly executable.

In file @apps/server/src/orchestration-v2/Adapters/OpenCodeAdapterV2.testkit.ts around line 180:

The `events` async generator emits an event **after** the subscription has been aborted. The signal is only checked at the top of each loop iteration, so if an abort arrives during the `Effect.sleep(Duration.millis(entry.afterMs))` delay, the generator still advances the cursor and yields the event instead of stopping. This also means any teardown waiting on the stream to end can remain blocked for the full `afterMs` duration. Consider awaiting the sleep with an `AbortSignal` race (or re-checking `signal?.aborted` after the delay, before yielding) so an abort during the delay stops the generator immediately.

In file @apps/server/src/orchestration-v2/testkit/fixtures/shared.ts around line 571:

When a `steer` or `restart` step is immediately followed by `answer_next_user_input_request`, the generated timeline pushes `await_thread_idle` before the answer step. The run cannot become idle until the user-input answer is sent, so the fixture deadlocks and times out. The follow-up check at line 571 and the matching check at line 605 only skip the idle-wait for `approve_next_runtime_request`; they need to also skip it for `answer_next_user_input_request`.

In file @apps/server/src/orchestration-v2/CheckpointRollbackService.ts around lines 111-113:

`runsToRollback` filters only runs with `status === "completed"`, so runs that are `failed`, `cancelled`, or `interrupted` are silently excluded from the rollback events. The filesystem checkpoint is restored, but these terminal runs (and their nodes) are never marked `rolled_back` in the event log, leaving stale state that incorrectly appears to be after the target checkpoint. Additionally, when all runs after the target ordinal are non-completed terminal runs, `runsToRollback.length === 0` evaluates true and `session.rollbackThread` is skipped entirely — the provider conversation is not rolled back even though the filesystem was. Consider including all terminal run statuses (or all runs with `ordinal > targetOrdinal`) so the persisted run state and provider thread are both rolled back consistently.

In file @apps/server/src/orchestration-v2/RunExecutionService.ts around line 211:

The cascade in `cascadeTerminalizeRunOwnedSubagents` writes every child-thread `node.updated` event with `input.run.providerInstanceId` instead of the node's own `node.providerInstanceId`. Child subagent nodes can run on a different provider instance than the root run, so this stamps the wrong provider instance on the event's top-level `providerInstanceId` field. Instance-indexed event logs or instance-scoped readers will see the node attributed to the wrong provider. Consider using `node.providerInstanceId` for the cascaded `node.updated` event (and the turn item's own instance identity where available).

In file @apps/server/scripts/record-codex-app-server-replay-fixture.ts around line 188:

`parseScenarios` silently falls back to recording the `simple` fixture when `--scenario` is supplied with no following value, instead of rejecting the malformed CLI invocation. For example, a command ending in `--scenario` overwrites the `simple` fixture rather than erroring. This happens because `readArgValues` drops any `--scenario` occurrence that lacks a following value, so `rawValues` is empty and line 188 substitutes `["simple"]`. Consider treating a valueless `--scenario` as a CLI error.

In file @apps/web/src/components/chat/MessagesTimeline.tsx around line 1594:

The expand/collapse button in `WorkGroupSection` is missing the `aria-expanded` attribute. Screen-reader users can activate the "Show more/fewer" toggle, but the button does not expose whether the group is currently expanded or collapsed, so the control's state is invisible to assistive technology. Consider adding `aria-expanded={isExpanded}` to the button.

In file @apps/server/src/orchestration-v2/ProviderContinuationService.ts around lines 74-80:

When `dispatchContinuation` fails before reaching `request.dispatchIfCurrent` (e.g. `getThreadProjection` or ID allocation throws), the worker catches and logs the error but never calls `request.clearIfCurrent`. The adapter's sticky `continuationRequested` flag stays set, so the adapter refuses to offer another request and the provider continuation is permanently stranded until the session is reset. Consider calling `request.clearIfCurrent` (or `request.dispatchIfCurrent(Effect.void)`) in the `catchCause` handler before logging so the adapter's sticky flag is cleared on failure.

In file @apps/server/src/project/ProjectService.ts around lines 188-193:

When a workspace root is reused by a new project after the original project was soft-deleted, `getByWorkspaceRoot` with `includeDeleted: true` returns the older deleted project instead of the active one. This yields stale metadata and the wrong `projectId` for callers that expect the current project occupying that workspace.

The method searches `listAll()` (ordered by creation time) with `find`, so it always selects the first matching row — which is the earliest created project — regardless of whether a newer, non-deleted project now owns the workspace. Consider selecting the active project first, falling back to deleted entries only when no active match exists.

In file @apps/server/src/orchestration-v2/RunExecutionService.ts around line 323:

`routeProviderEvent` accepts `app_thread.created` for any subagent whose parent thread is owned, regardless of which run or attempt spawned it. During a steer (superseded attempt), both the old and new attempts subscribe to events on the same root thread, so a child thread created by one attempt is added to the other attempt's routing state. Subsequent `node.updated`, `message.updated`, `turn_item.updated`, and `plan.updated` events for that child are then routed to and ingested by both attempts, writing the child's data under each caller's `runId` and corrupting the other run's projections. The `app_thread.created` lineage carries no run or attempt discriminator, so the parent-thread check alone cannot distinguish ownership between concurrent attempts on the same root thread. Consider tracking the run/attempt that created each child thread (e.g. by refusing `app_thread.created` events that arrive before the owning attempt has observed its own provider turn) or documenting why cross-attempt sharing of child threads is intentional.

In file @apps/server/src/orchestration-v2/Adapters/CursorAdapterV2.testkit.ts around line 742:

`restartBeforePromptIndex` is never range-validated. A negative value or an index `>= prompts.length` silently matches nothing in the prompt loop, so the recording completes without performing the requested agent close/resume sequence and produces a fixture that does not test the resume path. The other two interrupt fields validate their bounds; this one is missing the same check. Consider adding a guard rejecting values outside `0..prompts.length` (inclusive of `prompts.length` if a post-loop restart is intended).